The evolution of the LEP logging database

In January 1992, a project was started to create a system, using an on-line ORACLE database, to allow logging of a multitude of data on the Large Electron Positron Collider (LEP). The aim of this project was to log particle beam characteristics, physics parameters, hardware settings and environmental conditions. Storing and keeping track of this heterogeneous data for a period of at least one year would permit a better understanding of the behavior of the fairly new LEP Collider.After using the logging system for almost four years, nearly three years of which in full operation, the reliability and performance has been proved, endorsing the design of the database and surrounding software. Moreover, the large number of users of the logging database and the huge amount of new requests for data logging shows the high activity and usefulness of this system. Furthermore, in the context of the 1993 and 1995 energy scans, the logged data turns out to be indispensable for thorough monitoring of the LEP beam energy, which is affected by many parameters.Since the commissioning in 1992, the logging database has been subject to an ORACLE migration from version 6 to 7 and a hardware upgrade of the host platform, in order to keep in step with latest technology and future user requirements.This paper describes the evolution and present state of the LEP logging database

LEP Traceability

After more than ten years of production for high energy physics, CERN's current flagship, LEP, will be closed down definitively October 1st, 2000. Starting immediately, some 30,000 tonnes of LEP materials will be removed from the tunnel to make room for LHC installation. The dismantling project is a major undertaking in terms of resources and constraints, which has to be completed in less than one year. Moreover, since LEP is classified as a nuclear installation in France (as if it was a nuclear power plant), special procedures have to be followed in addition to the normal environmental and safety issues. One major facet of the project is the "traceability" of everything that comes out of the LEP tunnel. This implies that each piece of equipment must be identified and tracked from its origin through any temporary storage to its final destination. Special procedures have to be followed for all materials even if they are not radioactive. As much of the equipment as possible will be recycled or disposed of. This paper describes the database design, software and procedures that are envisaged for the implementation of the LEP traceability system

The LHC Logging Service: Capturing, storing and using time-series data for the world's largest scientific instrument

CERN, the European Laboratory for Particle Physics, is well underway in building the most powerful particle accelerator called LHC (Large Hadron Collider), which will probe deeper into matter than ever before. This circular 27-km long superconducting installation is extremely complex, and its functioning has to be closely monitored. The LHC Logging service is aimed to satisfy the requirement of capturing and storing of any relevant piece of information to track its variation over time. Web-deployed tools have been developed to visualize, correlate and export the data into dedicated off-line analysis tools. The quality of the data, the manageability of the service and the overall system performance are key factors for the service. Oracle technology has been used extensively to support this mission-critical service, which has proven already to be useful during the commissioning phase of individual subsystems of the LHC. The architecture, design and implementation of the LHC Logging service, based on Oracle Database, Application Servers and the Enterprise Manager, are described in this paper

The LSA Database to Drive the Accelerator Settings

The LHC Software Architecture (LSA), used to operate the particle accelerators at CERN, is dependent on an on-line database to manage both high and low level parameter settings, including their evolution over time. Accelerator optics models, control sequences, reference values, are amongst the other entities being managed within the database. The LSA database can be considered as being located between the operators and the accelerators; therefore performance, availability, and security of the service as well as data integrity are paramount. To meet these requirements the LSA database model has been carefully developed, all database access is tightly controlled and instrumented, business logic is implemented within the database, and there is a semi-automatic integration with other key accelerator databases. Currently 8.6 million settings for some 40 thousand devices of the LEIR, SPS, and LHC accelerators are being effectively managed

Rapid Development of Database Interfaces with Oracle APEX, used for the Controls Systems at CERN

The need to rapidly prototype, build and deploy applications and to be able to react immediately to the changing user requirements is a challenge facing every enterprise. CERN – the largest particle research centre in the world – has tremendous data storage requirements, encompassing many different databases and has to quickly provide interfaces to visualize the data. This article will cover how Oracle APEX has been used to build several different database-centric interfaces related to the accelerator complex. Real-world applications will be discussed and it will be shown how Oracle APEX has met the preliminary requirements of the application developers and the user community at CERN. The article will address the question of when APEX could be a suitable choice of application development technology, and will share a developer's first-hand experience of both the good and bad points

Kinetic models of diagenesis in disturbed sediments Part 2. Nitrogen diagenesis

This article is in Free Access Publication and may be downloaded using the “Download Full Text PDF” link at right. © 1977, by the Association for the Sciences of Limnology and Oceanography, Inc.SCOPUS: ar.jFLWINinfo:eu-repo/semantics/publishe

On-Change Publishing of Database Resident Control System Data

The CERN accelerator control system is largely data driven, based on a distributed Oracle® database architecture. Many application programs depend on the latest values of key pieces of information such as beam mode and accelerator mode. Rather than taking the non-scalable approach of polling the database for the latest values, the CERN control system addresses this requirement by making use of the Oracle Advanced Queuing – an implementation based on JMS (Java Message Service) – to publish data changes throughout the control system via the CERN Controls Middleware (CMW). This paper describes the architecture of the system, the implementation choices and the experience so far

Percolation of Immobile Domains in Supercooled Thin Polymeric Films

We present an analysis of heterogeneous dynamics in molecular dynamics simulations of a thin polymeric film, supported by an absorbing structured surface. Near the glass transition "immobile" domains occur throughout the film, yet the probability of their occurrence decreasing with larger distance from the surface. Still, enough immobile domains are located near the free surface to cause them to percolate in the direction perpendicular to surface, at a temperature near the glass transition temperature. This result is in agreement with a recent theoretical model of glass transition

Accelerator Data Foundation : How it all fits together

Since 2003, a coherent data management approach was envisaged for the needs of installing, commissioning, operating and maintaining the LHC. Data repositories in the distinct domains of physical equipment, installed components, controls configuration and operational data have been established to cater for these different aspects. The interdependencies between the domains have been implemented as a distributed database. This approach, based on a very wide data foundation, has been used for the LHC and is being extended to the CERN accelerator complex

Mission critical database for SPS accelerator measurements

In order to maintain efficient control over the hadron and lepton beams in CERN¹s SPS accelerator, measurements are of vital importance. Beam parameters such as intensities, positions and losses need to be rapidly available in the SPS control room to allow the operators to monitor, judge and act on beam physics conditions. For the 1994 SPS startup, a completely new and redesigned measurement system based on client and server C-programs running on UNIX-workstations was introduced. The kernel of this new measurement system is an on-line ORACLE database.The NIAM method was used for the database design as well as a technique to tag synchronized data with timeslots instead of timestamps. A great attention was paid to proper storage allocation for tables and indices since this has a major impact on the efficiency of the database, due to its time-critical nature. Many new features of Oracle7 were exploited to reduce the surrounding software.During the 1994 SPS physics run, this new measurement system was commissioned successfully and the infrastructure proved to be acceptably reliable. Hence, for the 1995 startup, the size of the measurement system was increased drastically to fulfill a variety of measurement needs. This proliferation of measurements beyond the initial scope showed the correct design of the system, as well as the performance limitations within the actual hardware configuration. This paper describes the overall design and discusses performance issues of this critical system